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Research  Institute,  and  Softech  determined  requirements  for  and  developed  the  Instructional 
Support  System  (ISS).  The  basis  for  this  development  was  the  Advanced  Instructional  System 
(AIS),  a  computer-based  Instructional  system  developed  Jointly  by  AFHRL  and  McDonnell  Douglas 
Astronautics  Company. 

Early  In  the  project,  McDonnell  Douglas  teamed  with  Denver  Research  Institute  to  determine 
the  functional  requirements  of  the  ISS.  An  examination  of  key  DOD  training  systems  occurred  to 
determine  the  feasibility  of  adding  certain  key  features  to  the  ISS  at  reasonable  cost.  Also, 
several  key  DOD  training  environments  were  examined  to  determine  training  requirements  the  ISS 
would  need  to  address.  Existing  AIS  capabilities  as  well  as  Inputs  from  these  DOD  analyses  were 
used  to  create  a  Functional  Description  of  the  ISS.  Existing  AIS  software  which  best  satisfied 
the  Functional  Description  were  then  converted. 

Nine  basic  applications  software  modules,  comprising  approximately  TOO, 000  lines  of  source 
code,  exist  as  a  result  of  the  conversion.  They  are  CAI  Authoring,  CAl  Presentation,  Graphics, 
Simulation  Authoring,  Simulation  Presentation,  CMI  Development,  CMl  Operation,  Data  Analysis,  and 
Access/Security. 

A  translator  was  developed  by  McDonnell  Douglas  and  Softech  to  assist  In  the  conversion  from 
CAMIL  (Computer-Assisted/Managed  Instructional  Language),  the  primary  language  of  Implementation 
for  the  AIS,  to  Ada,  the  primary  language  of  Implementation  for  the  ISS.  The  translator  was 
capable  of  translating  approximately  80%  of  a  CAMIL  program  to  correct  Ada.  Approximately  20%  of 
a  CAMIL  program  was  either  partially  translated  or  untranslated.  These  areas  were  clearly  marked 
with  manual  translation  hints  In  the  resultant  Ada. 

The  ISS  Application  Support  Environment  (ASE)  was  developed  concurrently  with  conversion  of 
the  applications  software.  The  purpose  of  the  ASE  is  twofold:  First,  It  provides  portability  to 
the  ISS,  given  that  machine  and  operating  system  dependencies  are  Implemented  at  the  lowest  level 
of  the  support  environment;  second.  It  provides  a  variety  of  basic  runtime  support  services  to 
ISS  applications  software  to  assist  In  the  areas  of  user  Interaction,  data  processing,  and 
storage  and  retrieval  of  data. 


Finally,  an  Important  aspect  in  the  success  of  the  Standardized  Software  project  was  a 
microcomputer  analysis,  conducted  to  analyze  and  reconmend  small  machines  capable  of  executing 
ISS  software  modules.  An  MC68000  basic  Pacific  Microcomputer  PM200  was  procured  by  the  Air  Force 
as  a  result  of  the  study.  Key  software  modules  were  successfully  compiled  and  executed  on  the 
system,  demonstrating  the  concept  of  ISS  transportability  and  feasibility  of  running  the  ISS  on  a 
microcomputer. 
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INSTRUCTIONAL  SUPPORT  SOFTWARE  SYSTEM 


1.0  INTRODUCTION 

TNt  prototype  Advanced  Instructional  System  (AIS)  was  designed  as  a  research  and  development 
test  bed  for  technical  training.  As  such.  It  demonstrated  that  Individualized  computer-assisted 
Instruction  (CAI)  and  computer-managed  Instruction  (CMI)  are  directly  applicable  to  an 
operational  Air  Force  training  environment. 

Although  demonstrated  as  feasible,  the  original  system  was  not  transportable;  therefore, 
exploitation  of  the  training  technology  was  limited.  In  order  to  correct  this  problem,  the 
Technical  Training  Division  of  the  Air  Force  Human  Resources  Laboratory  (AFHRL)  awarded  a 
contract  to  the  McDonnell  Douglas  Astronautics  Company  to  create  a  transportable  system.  This 
Standardized  Software  project  had  as  the  major  goal  to  create  a  transportable  Instructional 
system  that  Is  Implementable  on  1ow-cost  minicomputers  and  microcomputers  In  order  to  expand  Into 
the  appropriate  ODD  training  environments.  The  transportable  system,  called  the  Instructional 
Support  Software  (ISS)  system,  has  been  developed  and  alpha  tested.  An  operational  test  of  the 
system  Is  projected  to  begin  during  the  third  quarter  of  1985. 

The  Air  Force  set  forth  several  key  requirements  to  accomplish  Its  major  goal.  It  was 
decided  that  Ada,  the  newly  standardized  DOD  language,  would  be  used  to  enhance  system 
portability*  Ada  Is  the  Ideal  language  In  which  to  Implement  transportable  software,  given  Its 
mission  as  a  standard  high-order  language  that  will  become  available  on  many  machines. 

Another  requirement  was  to  develop  a  set  of  generalized  Interfaces  to  enhance  portability. 
By  embedding  machine  dependencies  low  Into  the  ISS  support  software,  the  necessary  Interface  to 
the  host  operating  system  could  be  accomplished  In  a  portable  way. 

The  final  key  requirement  was  to  create  application  software  made  up  of  modular  components  to 
support  the  execution  of  Individual  portions  of  the  ISS.  Components  such  as  Authoring,  Graphics, 
and  CAI  Presentation  were  to  be  created  for  execution  on  an  Individual  basis.  By  allowing 
potential  DOD  customers  the  capability  to  choose  only  a  subset  of  the  entire  ISS,  particular 
needs  can  be  met  at  lower  cost. 

In  order  to  report  the  significance  and  results  of  the  Standardized  Software  project,  the 
following  sections  of  this  report  will  provide  a  project  description,  a  statement  of  the  major 
accomplishments  of  the  project.  Information  on  ISS  potential,  and  conclusions  and  recommendations. 


2.0  PROJECT  DESCRIPTION 

Early  In  the  project,  McDonnell  Douglas  teamed  with  the  Denver  Research  Institute  to 
determine  the  functional  requirements  of  the  ISS.  Key  DOD  training  systems  were  examined  to 
determine  the  feasibility  of  adding  certain  key  features  to  the  ISS  at  reasonable  cost.  Also, 
several  key  DOD  training  environments  were  examined  to  determine  what  training  requirements  the 
ISS  would  need  to  address.  Existing  AIS  capabilities,  as  well  as  Inputs  from  these  DOD  analyses, 
were  used  to  create  a  functional  description  of  the  ISS.  Existing  AIS  software  which  best 
satisfied  the  functional  description  was  then  converted. 

Nine  basic  application  software  modules,  comprising  approximately  300,000  lines  of  source 
code,  exist  as  a  result  of  the  conversion.  They  are  CAI  Authoring,  CAI  Presentation,  Graphics, 
Simulation  Authoring,  Simulation  Presentation,  CMI  Development,  CMI  Operation,  Data  Analysis,  and 
Access/Security. 


A  translator  was  developed  to  assist  In  the  conversion  from  CAMIL  (Computer-Asslsted/Managed 
Instructional  Language),  the  primary  language  of  Implementation  for  the  AIS,  to  Ada,  the  primary 
language  of  Implementation  for  the  ISS.  The  translator  was  capable  of  translating  approximately 
80t  of  a  CAMIL  program  to  correct  Ada.  Approximately  20t  of  a  CAMIL  program  was  either  partially 
translated  or  untranslated.  These  areas  were  clearly  marked  with  manual  translation  hints  In  the 
resultant  Ada. 

The  ISS  Application  Support  Environment  (ASE)  was  developed  concurrently  with  conversion  of 
the  application  software.  The  purpose  of  the  ASE  Is  twofold.  First,  It  provides  portability  to 
the  ISS,  given  that  machine  and  operating  system  dependencies  are  Implemented  at  the  lowest  level 
of  the  support  environment.  Second,  It  provides  a  variety  of  basic  runtime  support  services  to 
ISS  application  software  to  assist  In  the  areas  of  user  Interaction,  data  processing,  and  storage 
and  retrieval  of  data. 

Finally,  an  Important  aspect  In  the  success  of  the  Standardized  Software  project  was  a 
microcomputer  analysis,  conducted  to  analyze  and  recommend  small  machines  capable  of  executing 
ISS  software  modules.  An  MC68000-based  Pacific  Microcomputer  PM200  was  procured  by  the  Air  Force 
as  a  result  of  the  study.  Key  software  modules  were  successfully  compiled  and  executed  on  the 
system,  demonstrating  the  concept  of  ISS  transportability  and  the  feasibility  of  running  the  ISS 
on  a  microcomputer. 


3.0  MAJOR  ACCOMPLISHMENTS 

The  goals  set  forth  at  the  beginning  of  the  Standardized  Software  project  have  been 
accomplished.  Applications  software  which  best  satisfies  the  functional  description  has  been 
converted  or  developed.  The  developed  system  Is  portable.  After  the  software  had  first  been 
produced  on  the  development  machine  (VAX-11/780)  and  then  transported  to  the  PM200  microcomputer, 
the  concept  of  portability  had  been  demonstrated.  And  finally,  the  system  has  been  Implemented 
on  a  low-cost  minicomputer  and  microcomputer. 

The  ISS  Is  organized  using  a  layered  shell  approach  to  allow  for  maximum  ease  of  maintenance 
and  transportability.  The  design  philosophy  of  the  software  Is  depicted  In  Figure  1.  ISS  users 
Interface  with  a  set  of  programs  called  the  Applications  Software  (described  In  Section  3.1). 
The  next  layer  of  software,  called  the  Application  Support  Environment,  performs  the  Interfacing 
tasks  necessary  to  support  the  Applications  Software.  The  Innermost  layer  Is  the  Operating 
System  Software.  This  software  provides  Interface  to  the  computer  hardware.  The  advantage  of 
this  layered  approach  Is  that  changes  In  basic  hardware  configuration  or  operating  system 
software  are  unlikely  to  adversely  affect  the  ISS  Applications  Software.  The  Applications 
Software  Is  buffered  by  a  layer  of  support  environment  software  that  performs  the  Interfacing 
between  Applications  Software  and  the  operating  system  and  hardware. 

The  following  sections  discuss  In  more  detail  the  major  accomplishments  during  the  project. 


3.1  Converted  Applications  Software 

With  the  ISS  software  modules,  a  user  Is  able  to  develop.  Implement,  and  evaluate  training. 
Table-driven  database  programs,  called  editors,  are  dominant  In  the  system,  thereby  allowing  a 
user  to  easily  Insert,  display,  and/or  change  Information  In  the  database.  The  most  Important 
characteristic  of  the  editors  Is  that  they  allow  quick  access  to  the  database  via  menus  and 
prompts.  No  computer  programming  skills  are  necessary  for  ISS  system  users. 
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Figure  1.  ISS  SoftMare  Structure. 

The  applications  software  Is  divided  Into  two  major  functions:  the  CAI  system  and  the  CMI 
system.  The  former  provides  the  development  and  delivery  capability  for  on-line  CAI,  while  the 
CMI  system  controls  the  administrative  and  management  functions  for  a  given  Installation.  Both 
systems  are  Integrated  Into  the  ISS  package  and  share  a  cornnon  base  of  data  and  utility  programs. 

The  CAI  system  allows  nonprogranmers  to  develop  and  evaluate  Individualized,  interactive  CAI 
modules  containing  a  variety  of  text  and  graphics.  Using  the  CAI  editors,  development  of 

courseware  takes  the  form  of  an  ongoing  dialog  between  the  author  and  the  system.  There  are 
three  major  authoring  programs  In  the  CAI  software:  CASS,  SID,  and  GraphEdIt.  CASS  Is  the 

screen-frame-oriented,  courseware-authoring  editor  that  guides  the  author  via  the  use  of  menus. 
SID  Is  an  actlon-to-screen-orlented  simulation  courseware  authoring  editor  that  also  guides  the 
author  via  menus.  GraphEdIt  Is  a  graphics  creation  editor  for  CASS  and  SID  that  guides  the 
graphics  artist  through  Input  from  many  possible  sources  such  as  the  keyboard,  a  digitizer 
tablet,  a  touch  panel,  a  joy-disk,  or  a  light  pen.  Like  the  other  editors,  GraphEdIt  Is 

menu-driven. 

CAI  lessons  are  delivered  to  students  through  CAI  software  modules:  CAI  Presentation 
(CAIPres)  and  Simulation  Presentation  (SlDPres).  These  modules  provide  the  student  with  all  CAI 
and  simulation  lessons  and  allow  for  Interaction,  screen  dynamics,  branching,  remediation, 
feedback,  and  prompts.  Like  the  authoring  modules,  CAIPres  and  SlOPres  are  menu-driven  and 
user-friendly. 


The  CMI  system  provides  comprehensive  management  Information  and  administration 
Implementation.  It  controls  the  scheduling  of  assignments,  testing,  remediation,  and  enrichment 
activities  for  each  student. 
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Four  major  editors  assist  the  curriculum  developer  in  describing  the  curriculum.  By  using 
these  four  editors,  the  Curriculum  Definition  Editor  (CDE),  the  Course  Structure  Editor  (CSE) 
the  Lesson  Definition  Editor  (LDE),  and  the  Test  Editor  (TESTED),  curriculum  developers  and 
managers  can  define  increasingly  detailed  characteristics  of  a  curriculum.  After  the  development 
task  Is  complete,  the  CMI  operation  programs  administer  the  curriculum. 

Student  registration,  course  structure  management,  resource  management,  and  student 
self-pacing  are  maintained  by  three  CMI  programs  comprising  the  CMI  operations  module.  The 
programs  are  Student  Logon,  Student  Registration,  and  the  Adaptive  Model. 

Evaluation  of  individual  student  and  overall  course  progress  is  monitored  and  recorded  by 
three  CMI  evaluation  programs  comprising  the  Data  Analysis  module.  The  programs  are  Course 
Evaluation  Summary  (CES).  Test  Item  Evaluation  (TIE),  and  the  Data  Extraction  Program  (DEP). 
These  programs  report  data  such  as  the  standard  deviation/mean  times  and  test  scores  for  a 
lesson,  course,  or  entire  curriculum  (CES).  determine  standard  deviation/mean  time  and  scores  for 
specific  tests  and  test  items  (TIE),  and  select  any  available  data,  ad  hoc,  to  run  analysis  for 
curriculum  evaluation  and  student/group  performance  (DEP). 

The  Access/Security  module  is  used  to  define  the  access  a  user  will  have  to  the  ISS.  The 
Access/Security  software  is  necessary  to  allow  operation  of  all  of  the  other  ISS  software.  The 
software  contains  two  programs:  USRED  and  LOGON. 

Users  of  a  computer-based  training  system  are  typically  concerned  with  the  security  measures 
that  control  access  to  the  system.  USRED  allows  system  managers  to  control  access  to  all  ISS 
components  and  software.  It  identifies  users,  database  programs,  and  courses  to  the  ISS  system 
and  authorizes  and/or  restricts  the  access  of  individual  users  to  ISS  editors,  database  programs.’ 
and  courses.  USRED  can  also  regulate  a  user's  level  of  access  within  a  specific  editor,  database 
program,  or  course.  One  may,  for  example,  give  a  user  permission  to  add  and/or  change 
information  In  a  specific  course,  but  not  to  delete  information.  One  may  give  another  user 
permission  to  display  information  but  not  to  manipulate  it  in  any  way. 

The  LOGON  program  provides  all  users  with  access  to  the  ISS.  It  also  functions  as  a  security 
checkpoint  by  requiring  the  user  to  enter  a  specific  ID  followed  by  a  specific  password.  LOGON 
compares  the  Information  entered  by  the  user  with  information  that  has  been  stored  by  USRED  in 
the  user  record.  If  no  match  is  found,  LOGON  Instructs  the  user  to  reenter  the  data. 

Students  entering  LOGON  are  automatically  transferred  to  the  Student  Logon  program.  Once  in 
Student  Logon,  a  student  user  can  interact  with  the  ISS  for  training  activities. 

Non-student  users  are  admitted  to  the  system  via  LOGON.  Here,  the  user  is  presented  with  a 
list  of  editors  and  database  programs  that  have  been  authorized  the  user  via  USRED. 


3.2  CAMlL-to-Ada  Translator 

A  translator  has  been  developed  to  assist  in  the  conversion  from  CAMIL  (AIS-3.8-1 674,  1979) 
to  Ada.  The  translator  is  capable  of  translating  approximately  80t  of  a  CAMIL  program  to  correct 
Ada  (ANSI/MIL-STD-1815A,  1983).  Approximately  20%  of  a  CAMIL  program  is  either  partially 
translated  or  untranslated.  These  partially  or  untranslated  areas  are  clearly  marked  with  manual 
translation  hints  in  the  resultant  Ada.  Figure  2  illustrates  the  mechanism  used  to  translate  a 
CAMIL  program  to  Ada  and  to  compile  and  link  that  Ada  program  into  executable  form. 
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Figure  2.  Autoutic  Translation  froa  CAMIL  to  Ada. 

The  functional  units  that  comprise  the  translator  are  generally  the  same  as  those  that 
comprise  the  CAHIL  compiler.  The  major  differences  In  the  translator  functional  units  are  as 
follows:  (See  Figure  3  and  0D1017F019,  1974.) 

1.  Modification  of  production  action  routines. 

2.  Replacement  of  code  generation  routines  with  Ada  source  generation  routines. 

3.  Additions  to  data  structures  for  symbol  and  type  table  entries. 

Other  minor  differences  exist.  For  example,  the  translator  version  of  the  lexical  analyzer 
and  parser  saves  Information  about  comments  appearing  In  the  source  so  that  they  may  be  preserved 
In  the  Ada  translation.  Figure  3  Illustrates  the  combined  top-level  functional  decomposition  of 
the  CAMIL  compiler  and  the  translator.  Note  that  the  portion  labeled  Code  Generator  Is  part  of 
the  CAMIL  compiler  and  Is  replaced  by  the  Translation  Routines  and  Ada  Source  Generator  in  the 
translator.  All  the  other  top-level  functional  units  are  shared  by  both  the  compiler  and  the 
translator  (with  the  differences  already  mentioned).  Sections  3.2.1  and  3.2.2  contain  a  general 
description  of  how  a  translation  Is  accomplished. 


3.2.1  Translator  Action  Routines 

Each  time  the  translator's  parser  recognizes  a  particular  construct  or  portion  of  a  construct 
(called  production)  In  the  CAMIL  language.  It  Invokes  an  associated  action  routine.  These  action 
routines  are  responsible  for  checking  semantic  restrictions  and  building  data  structures  (called 
semantic  frames)  to  represent  the  construct  recognized.  Syntax  checking  is  done  by  the  parser. 

The  semantic  frames  generated  by  action  routines  are  placed  on  a  stack  which  is  pushed  and 
popped  by  the  parser  as  constructs  are  recognized.  In  this  way,  an  action  routine  for  a 


1ow>1«vel  production  (for  example,  one  that  processes  an  operator  expression)  can  pass 
Information  about  that  production  to  another  action  routine  associated  with  a  higher  level 
production  (for  example,  an  assignment  statement  production  In  which  the  operator  expression 
forms  the  r1ght*hand  side). 

The  action  routines  representing  the  declaration  productions  (e.g.,  variable  declarations) 
build  symbol  and  type  table  entries  using  Information  that  has  been  saved  In  semantic  frames  by 
action  routines. 

Similarly,  action  routines  Invoked  for  statement  level  productions  (e.g.,  assignment)  call 
translation  routines  to  generate  code  passing  them  Information  saved  In  semantic  frames  (e.g., 
variable  and  expression  frames)  built  by  lower  frames  (on  the  parser  stack),  which  represent  the 
parts  of  the  right-hand  side  of  the  semantic  production.  The  action  routine  usually  generates  a 
new  semantic  frame  that  Is  Input  to  higher  level  productions;  however,  some  action  routines 
generate  a  symbol  or  type  table  entry  and/or  call  a  translation  routine  to  generate  Ada  source 
code. 


3.2.2  Translation  Routines 

The  translation  routines  are  organized  In  a  manner  that  roughly  parallels  the  productions. 
These  routines  are  Initially  Invoked  by  statement  level  action  routines  and  Internally  Invoke 
each  other  to  complete  translation  of  a  statement.  The  transition  routines  call  the  routines  In 
the  Ada  source  generator  that  actually  generate  the  source  string.  The  translation  routines 
operate  by  "walking"  through  the  semantic  tree  and  calling  Ada  source  generation  routines. 


3.3  Th<  <^p1tc«t1on  Support  Environ— nt 

The  purpose  of  the  Application  Support  Environment  Is  twofold.  First.  It  provides 
portability  to  the  ISS,  given  that  machine  and  operating  system  dependencies  are  Implemented  at 
the  lowest  level  of  the  support  environment.  (See  Section  3.4.)  Second.  It  provides  a  varietur 
of  basic  runtime  support  services  to  ISS  applications  software  to  assist  In  the  areas  of  user 
Interaction,  data  processing,  and  storage  and  retrieval  of  data. 

The  Application  Support  Environment  Is  divided  Into  two  layers:  the  Application  Support  Layer 
(ASL)  and  the  Virtual  Machine  Layer  (VML).  Figure  4  Illustrates  the  division  of  the  Application 
Support  Environment  In  order  to  support  the  applications  software  and  to  Interface  to  the  host 
operating  system.  This  section  of  the  report  describes  the  support  services  provided  •by  the  ASL 
to  the  applications  software.  The  VML  1$  discussed  In  Section  3.4.  The  ASL  provides  software  In 
the  areas  of  terminal  communications,  data  management.  Inter-process  communication,  text 
handling,  program  control .  and  mathematical  services. 


Figure  4.  ISS  Software  Structure  Illustrating  the  Divided 
Application  Support  Environment. 


3.3.1  Terminal  Communication 


The  Terminal  Coimunlcatlon  component  provides  the  functional  Interface  between  the  ISS 
applications  software  and  the  terminal  devices  used  to  communicate  with  applications  software 
users.  Terminal  devices  can  be  easily  added  since  Individual  terminal  characteristics  are  stored 
In  data  tables.  All  that  Is  necessary  for  the  ISS  to  support  a  new  terminal  type  Is  to  enter  the 
data  describing  the  new  terminal  Into  the  terminal  definition  table.  The  full  set  of  combined 


7 


text/graphics  display  characteristics  and  capabilities  provided  by  the  Tenainal  Coanuni cation 
conponent  are  as  follows: 

1.  Characters  per  line  range  from  60  to  128. 

2.  Lines  per  screen  range  from  24  to  64. 

3.  Lines  are  numbered  from  1  to  L  with  line  1  at  the  top  of  the  screen  and  line  L  at  the 
bottom  of  the  screen. 

4.  Columns  are  numbered  from  1  to  C  with  column  1  at  the  leftmost  character  cell  position 
and  column  C  at  the  rightmost  position. 

5.  Random  cursor  positioning  is  possible  to  at\y  character  position  within  the  character 
matrix  defining  the  screen. 

6.  Random  cursor  positioning  to  any  dot  position  within  the  dot  matrix  is  possible. 

7.  Double  height  and  width  characters,  as  well  as  normal  height  and  width  characters,  are 
display  able. 

8.  Lines  of  dots  from  the  current  dot  position  to  a  different  dot  position  are  displa^able. 

9.  Either  a  complete  or  partial  circle  of  dots  with  a  given  radius  is  displeyable,  starting 
at  the  current  cursor  position. 

10.  Text  and  graphics  are  displayable  in  eight  different  colors. 

11.  It  1$  possible  to  select  whether  background  or  foreground  elements  can  blink. 

The  terminal  keyboard  is  the  means  by  which  users  of  an  application  program  input  data  to 
that  program.  Keypresses  are  interpreted  by  the  Terminal  Communication  component  and  acted  upon 
where  appropriate.  Provisions  are  made  for  four  distinct  types  of  keys.  These  keys,  as  well  as 
the  set  of  keyboard  characteristics  and  capabilities,  are  as  follows: 

1.  Textual  Data  Keys  -  This  set  of  keys  represents  the  printable  character  symbols  as 
defined  in  the  ASCII  character  set. 

2.  Function  Keys  -  This  set  of  keys  has  special  meaning  to  the  Terminal  Communication 
component.  Entry  of  an  enabled  function  key  triggers  a  preemptive  transfer  of  control  from  the 
current  point  of  execution  within  an  application  program  to  a  handler  area  previously  declared 
within  the  program. 

3.  Action  Keys  -  This  set  of  keys  has  special  meaning  to  the  Terminal  Conmuni cation 
component.  Entry  of  an  action  key  causes  the  Terminal  Communication  component  to  act  on  the  data 
being  assembled  by  a  keyboard  read  operation  (e.g.,  deletion  of  a  character  by  pressing  the 
delete  key). 

4.  Terminal  Control  Keys  -  This  set  of  keys  has  special  meaning  to  the  Terminal 
Communication  component.  Each  terminal  control  key  represents  a  special  terminal  control 
function  which  can  be  performed  by  pressing  that  key.  The  terminal  control  functions  generally 
affect  the  current  display  screen  attributes  (e.g.,  color  and  blink). 


3.3.2  Data  Kanagawnt 

The  Data  Managenent  component  consists  of  the  ISS  database  and  the  necessary  operations 
required  by  the  applications  software  for  accessing  and  maintaining  the  database.  The  database 
Is  the  data  storage  system  for  all  of  the  data  objects  used  by  the  ISS  applications  software.  It 
supports  Indexed  Sequential.  Direct  Access,  and  Sequential  files.  The  names  of  the  files  are 
stored  In  a  directory  within  the  database  along  with  sufficient  additional  Information  necessary 
to  access  the  file.  A  file  cannot  span  disks  but  Is  otherwise  not  limited  In  size.  The 
characteristics  of  the  different  file  types  are  as  follows: 

1.  Indexed  Sequential  (ISAM)  Files  -  An  ISAM  file  Is  capable  of  containing  zero  or  more 
records,  each  of  which  may  contain  a  variable  amount  of  data.  For  each  ISAM  file  In  the  data 
base,  a  "key''  Is  defined  which  designates  that  a  specific  portion  of  each  record  be  used  to 
define  a  sequential  ordering  of  the  records  contained  In  that  file.  Each  record  Is  at  least  long 
enough  to  contain  the  entire  key.  An  Index  sufficient  to  map  key  values  to  record  locations.  In 
order  to  support  random  record  accessing.  Is  maintained  for  each  ISAM  file.  An  ISAM  key  can  be  a 
maximum  of  127  bytes. 

2.  Direct  Access  (DA)  Files  -  A  DA  file  Is  capable  of  containing  zero  or  more  records,  each 
of  which  may  contain  a  variable  amount  of  data.  Each  record  within  a  DA  file  Is  associated  with 
a  relative  record  number  which  defines  the  sequential  ordering  of  the  records  contained  In  that 
file.  An  Index  sufficient  to  map  relative  record  numbers  to  record  locations.  In  order  to 
support  random  record  accessing.  Is  maintained  for  each  Direct  Access  file.  The  maximum  relative 
record  number  In  use  for  each  file  Is  maintained  In  order  to  facilitate  the  allocation  of  unused 
relative  record  numbers  to  new  records  entered  Into  that  file. 

3.  Sequential  Files  -  A  sequential  file  Is  capable  of  containing  zero  or  more  records,  each 
of  which  contains  a  variable  amount  of  data.  The  records  within  a  sequential  file  have  a 
sequential  ordering  based  on  the  order  that  the  records  were  written  Into  the  file. 


3.3.3  Inter-Process  Communication 

The  Inter-Process  Comnunl cation  component  provides  a  set  of  functional  capabilities  to 
applications  software  to  enable  concurrently  active  ISS  processes  to  communicate  among 
themselves.  Figure  5  depicts  that  communication.  The  process  Is  the  logical  unit  of  activity 
within  the  ISS  execution  environment  and  the  primary  entity  relating  to  Inter-Process 
Communication.  It  Is  an  active  computing  environment  that  can  support  the  sequential  execution 
of  one  or  more  programs.  Each  active  ISS  user  Is  associated  with  a  dedicated  process  and 
Interacts  with  ISS  application  programs  that  execute  within  this  dedicated  process.  The 
operating  system  used  by  ISS  systems  and  applications  software  supports  the  execution  of  multiple 
concurrent  processes;  therefore,  multiple,  concurrent  ISS  users  are  supported. 

Each  active  ISS  process  Is  associated  with  a  system-wide  ISS  Process  Index  Number  which 
uniquely  Identifies  that  process  within  the  system.  The  Process  Index  Number  Is  kept  across  the 
execution  of  multiple  ISS  application  programs.  At  the  completion  of  an  ISS  process,  the  Process 
Index  Number  Is  deallocated,  allowing  other  processes  to  reuse  the  number. 


3.3.4  Text  Handling 

The  Text  Handling  component  provides  a  set  of  functional  capabilities  to  ISS  applications 
software  to  manipulate  text  for  display,  comparison,  assignment,  examination,  and  conversion 
to/from  non-textual  data  types.  Two  data  types  comprise  textual  data  In  the  ISS:  String  and 
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Character.  String  and  Character  data  contain  one  or  more  characters  of  ASCII  encoded  data 
representing  dlsplayable  characters  or  control  characters.  String  data  may  also  contain  generic 
codes  that  specify  functions  to  be  accomplished  by  the  Terminal  Comnunicatlon  component. 

A  string  has  an  actual  length  and  a  maximum  length  associated  with  It.  A  variable  string  has 
a  termination  character  to  Indicate  the  actual  length,  with  the  maximum  length  Indicated  at  the 
time  of  declaration.  For  the  string  declaration 

S  :  STRING  (1..5); 

the  maximum  length  Is  5.  By  Initializing  "S"  with  the  assign  string  procedure 
ASST(S,  "ABC"); 

the  actual  length  Is  set  at  3.  s'  would  appear  as  "ABCtc"  In  computer  memory,  where  tc  Is  the 
termination  character.  If  the  actual  length  of  a  variable  string  Is  equal  to  the  maximum  length, 
then  no  termination  character  Is  stored  In  the  string.  The  actual  length  Is  determined  to  be  the 
maximum  length  when  the  appropriate  string-handling  procedures  detect  no  termination  character. 


3.3.5  Program  Control 


The  Program  Control  component  provides  services  to  assist  In  the  control  of  the  execution 
flow  of  ISS  programs.  The  design  of  existing  software  for  the  ISS  assumes  some  additional 
execution  control  flow  capabilities  beyond  those  available  In  the  ISS  Implementation  language, 
Ada.  The  services  provided  by  Program  Control  are  as  follows: 
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1.  ProgrM  Transfer  -  An  ISS  program  Is  able  to  designate  which  program  should  execute 
within  the  current  process  after  the  current  program  terminates  Its  execution. 

2.  Inter-Program  Data  Passage  -  An  ISS  program  Is  capable  of  passing  data  for  retrieval  by 
the  next  program  specified  for  execution. 

3.  Timed  Walt  -  The  capability  exists  for  a  program  to  suspend  its  execution  for  a 
designated  time  Interval;  the  granularity  of  time  Is  .01  second. 

4.  Obtaining  Date  and  Time  of  Day  Information  -  The  capability  exists  for  obtaining  the 
current  date  (year,  month,  day,  and  Julian  date)  and  current  time  (hour,  minute,  and  second). 

5.  Obtaining  elapsed  and  central  processing  unit  (CPU)  Time  -  The  capability  exists  for 
obtaining  the  elapsed  and  CPU  time  for  a  session.  The  variables  returned  are  In  10-m11 11  second 
units. 


3.3.6  Mathematical  Services 

The  Mathematical  Services  component  provides  a  set  of  capabllltes  to  ISS  applications 
software  to  perform  trigonometric,  boolean,  exponentiation,  logarithmic,  and  other  miscellaneous 
mathematical  functions. 

Three  types  comprise  the  data  that  can  be  manipulated  by  the  mathematical  functions: 
INTEGER,  FLOAT,  and  BOOLEAN.  The  INTEGER  and  FLOAT  data  types  are  Implementation  defined  with 
respect  to  magnitude.  If  a  particular  host  supports  32-b1t  Integers,  for  example,  an  ISS  INTEGER 
will  be  32  bits.  If  a  host  supports  16-b1t  Integers,  an  ISS  INTEGER  will  be  16  bits.  The 
BOOLEAN  data  type  Is  represented  as  an  enumeration  type  In  the  following  way: 

type  boolean  Is  (false,  true); 


3.4  Software  Portability 

In  completing  the  design  and  Implementation  of  a  transportable  system,  ii  has  been  detenalned 
what  capabilities  are  necessary  In  candidate  systems  In  order  to  port  the  ISS  to  those  systems 
(Marshall,  1983).  Requirements  of  a  candidate  system  can  be  divided  Into  (a)  Ada  prograimaing 
language  requirements,  (b)  host  operating  system  requirements,  and  (c)  hardware  requirements 
(processor/perlpherals  and  terminal).  A  discussion  of  those  requirements  follows  In  the  next 
three  sections  of  this  report,  followed  by  a  section  describing  experience  transporting  the  ISS 
from  the  development  machine  (VAX-1 1/780)  to  the  PM200  microcomputer. 


3.4.1  Ada  Prograilng  Language  Requirements 

Since  the  ISS  Is  Implemented  In  the  Ada  language.  It  will  be  necessary  for  any  candidate 
system  to  provide  an  Ada  compiler.  Using  such  a  system  does  not  guarantee  successful 
Implementation  of  the  ISS,  however.  For  example,  some  existing  validated  compilers  Impose 
limitations  with  respect  to  code/data  sizes  and  pra^na  Implementation  (a  pragma  conveys 
Information  to  the  compiler  but  does  not  affect  the  correctness  of  a  program).  Also,  some 
existing  compilers  are  Incomplete  Implementations  and  do  not  provide  features  needed  by  the  ISS. 

If  code  and/or  data  are  limited  to  32k  or  64k  In  a  particular  Implementation  of  Ada,  some  ISS 
programs  will  not  execute  without  modification  on  that  system. 


Certain  pragmas  are  necessary  for  a  production  Implementation  of  the  ISS  (or  a  means  must  be 
devised  to  equivalently  Implement  the  effect  of  missing  pragmas).  If  the  pragma  PACK  does  not 
sufficiently  pack  data,  data  management  performance  will  degrade  because  records  will  be  much 
larger  than  If  packing  were  available.  If  the  pragma  INTERFACE  Is  not  provided  by  an  Ada 
compiler.  It  Is  awkward  to  interface  to  the  ISS  VML  procedures  (Figure  4)  that  are  necessary  to 
Implement  the  ISS.  If  the  pragma  SUPPRESS  Is  not  available,  costly  execution  time  checks  on 
subranged  Integer  assignments  and  array  bounds  will  constantly  occur,  causing  a  degradation  In 
performance  due  to  high  CPU  utilization.  Also,  while  the  pragma  INLINE  Is  not  required.  Its 
presence  Is  beneficial  since  sound  design  principles  can  then  be  used.  By  appropriately  using 
procedures  and  functions  and  declaring  them  to  be  compiled  Inline,  performance  Is  not  degraded 
due  to  costly  procedure  call  and  function  call  linkage. 

Note  that  In  certain  cases  It  may  be  possible  to  Implement  a  system  without  the  pragma  PACK, 
pragma  INTERFACE,  and  pragma  SUPPRESS.  Alternate  methods  causing  the  same  effect  should  always 
be  considered. 


3.4.2  Host  Operating  System  Requirements 

In  order  to  fulfill  ISS  functionality  and  performance  needs,  ASL  software  must  utilize  VML 
machine-dependent  procedures  (Figure  4).  These  VML  procedures,  written  In  a  non-Ada  language 
provided  by  the  host  system,  must  be  reimplemented  on  a  system  to  rehost  the  ISS  to  that  system. 
The  VML  procedures  are  of  two  different  forms:  (a)  procedures  that  call  host  operating  system 
software  to  gain  needed  functionality,  and  (b)  procedures  that  have  been  written  to  attain 
necessary  performance.  (These  procedures  are  Invoked  with  high  frequency  but  do  not  use 
operating  system  functions;  since  they  are  In  a  machine-dependent,  non-Ada  language.  It  can  be 
said  that  they  comprise  a  portion  of  host  operating  system  requirements.)  In  an  attempt  to 
minimize  the  size  of  the  VML,  the  number  of  procedures  has  been  kept  as  small  as  possible. 
Tables  1  and  2  describe  procedures  that  are  of  each  form.  To  clearly  depict  what  host  operating 
system  software  the  ISS  requires,  the  tables  specify  the  VML  entry  point  names  and  the 
functionality  requirements  fulfilled  (Table  1)  or  the  performance  requirements  fulfilled  (Table 
2).  Note  that  It  may  be  possible  to  Implement  some  of  the  VML  procedures  In  Ada  on  some  systems 
and  still  meet  the  functionality  and  performance  requirements.  Therefore,  In  evaluating  aqy 
future  candidate  system,  a  rigid  examination  should  not  occur  for  operating  system  capabilities 
that  match  exactly  the  requirements  given  In  Tables  1  and  2.  Where  appropriate,  equivalent  and 
acceptable  Implementations  for  fulfilling  requirements  should  be  considered. 


3.4.3  Hardware  Requirements 

Computer  hardware  Is  available  In  a  wide  range  of  varying  capacity,  functionality,  and 
performance.  This  section  of  the  report  describes  the  basic  requirements  of  a  hardware  system 
capable  of  developing  and  executing  the  ISS. 

It  Is  not  necessary  to  require  processor,  storage,  and  display  station  equipment  to  be 
packaged  either  together  In  a  desktop  unit  or  separately  In  order  to  successfully  develop  and 
execute  the  ISS  on  that  equipment.  For  clarity,  however,  processor/perl pheral  requirements  are 
described  separately  from  display  station  requirements. 


Table  1.  VHL  Procedures  Utilizing  Host  Operating  Siystea  Software 


VML  Entry  Point  Name 

1.  BACKSPC 

2.  CALL 

3.  CHILDACTIVE 

4.  CLOSET 

5.  DISMOUNT 

6.  EXP 

7.  FCLOSE 

8.  FCREATE 

9.  F6ETS 

10.  FOPEN 

11.  FPUTS 

12.  FREAO 

13.  FREENEM 

14.  FREMOVE 

15.  FSEEK 

16.  FWRITE 

17.  6ETT 

18.  GETJIATETIME 

19.  GET_TERM  INFO 

20.  GET  TIO  ~ 

21 .  GETJ-IMERS 

22.  GET  PIO 

23.  IBCiOL 

24.  INTOCHAR 

25.  LOW  LOCK 

26.  low" JNLOCK 

27.  MOu¥tT 

28.  NEWMEM 

29.  OPENT 

JO.  PGM_EXISTS 
J1 .  PUTT 
J2.  PRINTFILE 
J3.  RAND 

>4.  RESUMEPROCESS 

15.  REWINDT 

16.  RUNPGM 

>7.  RUNPROGRAM 

18.  SHIFT 

19.  STOPPROCESS 
0.  SUBNITFILE 

1 .  SUSPENDPROCESS 

2.  TEMPFILE 

3.  TRANLOG 

4.  TRAPMACHINEEXCEPTIONS 

5.  TRIG 

6.  UNIT_REAO 

7.  UNITJJRITE 

8.  WAIT 


Functionality  Requirement  Fulfilled 

Back  space  1  record  on  a  tape  file 
Call  procedure  with  absolute  address 
Check  for  an  active  sub-process 
Close  a  tape  file 
Dismount  a  tape 

Raise  e  to  power  of  Input  value 
Close  a  file 
Create  a  database  file 
Read  a  system  file  record 
Open  a  database  file 
Write  a  system  file  record 
Read  a  database  record 
Deallocates  dynamic  storage 
Remove  a  file 

Position  to  a  database  record 

Write  a  database  record 

Read  a  tape  record 

Return  the  current  date  and  time 

Return  Input  terminal  type 

Return  the  terminal  Identification 

Return  elapsed  and  CPU  time 

Return  the  process  Id 

Perform  specified  boolean  oper. 

Convert  an  Integer  to  a  character 

Lock  a  resource 

Unlock  a  resource 

Mount  a  tape 

Allocate  dynamic  storage 
Open  a  tape  file 
Determine  If  a  program  exists 
Put  a  tape  record 
Print  a  file 

Generate  a  random  number 

Resume  a  process 

Rewind  a  tape  file 

Run  a  non -background  program 

Run  a  background  program 

Perform  specified  shifting  oper. 

Stop  a  process 

Submit  a  command  file 

Suspend  a  process 

Create  a  name  for  a  system  file 

Translate  logical  to  actual  name 

Set  up  to  trap  machine  exceptions 

Perform  the  specified  trig  funct. 

Read  Input  from  a  terminal 
Write  output  to  a  terminal 
Halt  program  for  Input  time 


Table  2.  VML  Procedures  Fulfilling  Perfonunce  Requireaents 

VML  Entry  Point  Naae 

1 .  COMPAREHEM 

2.  FILLMEM 

3.  MOVEMEM 

4.  SEARCHMEN 

3.4. 3.1  Process/Peripheral  Requirements 

Following  Is  a  list  describing  the  minimum  processor  and  peripheral  requirements  for 
successfully  executing  the  ISS: 

1.  Processor  clock  of  at  minimum  8  MHz. 

2.  Capability  of  addressing  a  minimum  of  1  MB  of  random  access  memory  (RAM)  for  software 
development  and  ISS  execution. 

3.  A  minimum  of  40-MB  hard  disk  storage  for  operating  system,  program  development,  and  ISS 
applications  data  storage. 

4.  A  1-M8  floppy  disk  drive. 

Note  that  It  would  be  possible  to  Implement  a  more  restricted  version  of  the  ISS  on  a  system 
providing  less  process/perl pheral  capacities  than  those  listed. 

3. 4. 3. 2  Display  Station  Requirements 

Following  Is  a  list  describing  the  minimum  display-station  requirements  for  successfully 
presenting  ISS  displays: 

1.  Color  graphics  monitor:  An  Interactive  monitor  providing  both  alphanumeric  and  graphics 
display  capabilities  Is  necessary.  Any  mixture  of  text,  graphics,  and  background  colors  Is 
allowed.  Drawing  primitives  of  at  least  points,  vectors,  arcs,  circles,  and  rectangles  Is 
required.  It  Is  necessary  for  the  station  to  clip  picture  elements  so  that  screen  boundaries  are 
not  exceeded.  Color  and  blink  attributes  must  be  assignable  to  any  picture  primitive. 

Following  are  specific  monitor  requirements: 

a.  Screen  size  of  at  least  13-Inch  diagonal. 

b.  Dot  triad  spacing  of  0.31  mm  or  better. 

c.  At  least  42-Hz,  non-interlaced  refresh  rate  to  prevent  flicker. 

d.  Resolution  of  at  least  480  horizontal  by  360  vertical. 


Performance  Requirement  Fulfilled 

Efficiently  compares  two  ranges  of 
memory  locations 

Efficiently  Initializes  a  range  of 
memory  locations 

Efficiently  moves  one  range  of 
memory  locations  to  another  range  of 
memory  locations 

Efficiently  searches  a  range  of 
memory  locations  for  a  specified 
string  of  data 


e.  Blink  capability. 

f.  24  to  32  lines  with  ininimuin  of  80  character  lines. 

g.  480+  characters-per-second  writing  rate. 

h.  At  least  10  mlcroseconds-per-plxel  vector-writing  rate. 

2.  Keyboard  with  function  keys  and  numeric  pad. 

3.  96  standard  ASCII  characters  plus  varying  character  sizes. 

4.  If  not  provided,  expandable  to  support  light  pen,  touch  panel,  mouse,  or  other  pointing 
device. 

3.4.4  VAX-1 1/780  And  PM200  Impleowntatlons 

In  order  to  determine  the  portability  of  the  ISS,  software  Initially  Implemented  on  the 
VAX-11/780  has  been  Implemented  on  the  68000-based  PM200  microcomputer.  In  general,  key  ISS 
modules  ported  nicely  to  the  PH200  due  to  (a)  the  fulfillment,  by  the  PM200,  of  the  Ada 
programming  language  requirements,  host  operating  system  requirements  (UNIX),  and  hardware 
requirements  discussed  In  Sections  3.4.1,  3.4.2,  and  3.4.3  and  (b)  the  ease  with  which  the  VML 
was  reimplemented  on  the  PM200. 

The  VML  consists  of  approximately  2500  lines  of  FORTRAN  code  and  600  lines  of  Assembly 
language  code  on  the  VAX-11/780.  On  the  PH200,  the  VML  Is  approximately  1300  lines  of  code 
Implemented  In  the  C  language.  By  reimplementing  this  relatively  small  amount  of  software  to 
Interface  to  the  UNIX  operating  system  and  by  recompiling  the  Ada  source  on  the  PM200,  programs 
were  ported  with  relative  ease. 

It  should  be  emphasized  that  the  PM200  Implementation  was  to  demonstrate  the  feasibility  of 
ISS  transportability  and  the  execution  of  the  ISS  on  a  microcomputer.  Performance  and  Winchester 
disk  size  Issues  need  to  be  addressed  before  the  PM200  can  be  considered  a  production 
Implementation  (Section  5.0,  Conclusions  and  Recommendations). 

The  problems  encountered  In  porting  the  software  were  relatively  minor.  Differences  In  the 
command  languages  for  VAX  VMS  and  UNIX  had  to  be  reconciled  In  order  to  submit  programs  and  print 
Jobs.  An  open  file  limit  (17)  exists  In  UNIX  that  does  not  exist  In  VMS,  and  this  caused  minor 
modifications  to  some  application  programs.  And.  several  compiler  bugs  were  encountered  In  the 
Ada  compiler  on  the  PM200  (to  be  expected  for  early  Implementations  of  Ada),  causing  minor 
modifications  In  some  of  the  application  programs. 


4.0  ISS  POTENTIAL 

As  a  result  of  the  Standardized  Software  project,  significant  potential  uses  exist  for  the 
ISS:  (a)  organizations  currently  using  or  planning  to  purchase  hardware  upon  which  the  ISS  now 
operates  can  use  the  system  Immediately;  (b)  organizations  currently  using  or  planning  to 

purchase  a  system  upon  which  the  ISS  can  operate  will  be  able  to  use  the  ISS  after  Implementation 
of  the  Virtual  Machine  Layer  for  that  system;  (c)  depending  on  the  training  requirements  for  an 

organization,  the  ISS  can  be  delivered.  In  any  combination,  as  an  authoring  system,  a  CAI 

delivery  system,  and  a  CMI  system;  (d)  depending  on  the  training  requirements  for  an 

organization,  the  ISS  can  be  tailored  to  fulfill  those  requirements;  and  (e)  ISS  users  can 
reasonably  utilize  lower-cost  microcomputers,  such  as  the  system  used  In  the  Standardized 
Software  project,  to  perform  as  a  central  processor.  The  following  sections  elaborate  on  these 
potential  uses. 
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4.1  Current  laplfentatlons 


During  the  project,  the  ISS  was  Implemented  on  two  systems:  the  VAX-11/780,  using  the  VMS 
operating  system,  and  the  PM200.  using  the  UNIX  operating  system.  There  Is  significant  potential 
associated  with  each  Implementation. 

The  VMS  Implementation  Is  significant  In  that  It  Is  available  on  an  ever-broadening  and 
popular  series  of  machines.  Including  the  VAX-1 1/725,  VAX-1 1/730,  VAX-1 1/750,  VAX-1 1/780,  and  the 
Micro  VAX.  DOD  organizations  currently  using  or  planning  to  purchase  machines  from  the  VAX/VMS 
line  can  use  the  ISS  as  their  training  system. 

The  UNIX  operating  system  also  continues  to  gain  In  popularity.  Unlike  VMS  In  the  VAX  line. 
It  Is  Implemented  on  many  machines,  thereby  providing  an  excellent  opportunity  for  transportation 
of  the  ISS  technology. 

For  either  Implementation,  configuration  parameters  such  as  central  memory  size,  disk  storage 
space,  tape  storage  space,  and  terminal  type  should  be  carefully  considered  to  best  operate  the 
ISS  In  a  particular  training  environment. 


4.2  Future  Implementations 


In  addition  to  systems  utilizing  VMS  and  UNIX,  the  ISS  Is  Implementable  on  other  systems  that 
fulfill  the  language,  operating  system,  and  hardware  requirements  specified  In  Sections  3.4.1, 
3.4.2,  and  3.4.3.  The  capabilities  of  a  potential  system  should  be  examined  carefully  to 
determine  the  feasibility  of  ISS  Implementation.  For  a  system  fulfilling  the  requirements,  the 
Virtual  Machine  Layer  must  be  Implemented  In  order  for  the  ISS  to  operate  successfully  on  that 
system. 


4.3  The  Configurable  ISS 


Depending  on  the  training  requirements  for  an  organization,  the  ISS  can  be  delivered.  In  any 
combination,  as  a  CAI  authoring  system,  a  CAI  delivery  system,  and  a  CMI  system.  If  a  training 
environment  requires  CAI  that  has  not  been  developed,  a  method  to  systematically  and  efficiently 
create  courseware  Is  necessary.  The  software  modules  comprising  the  CAI  authoring  system  (CAI 
Authoring,  Graphics,  and  Simulation  Authoring)  provide  this  method.  If  CAI  presentation  Is 
required,  software  modules  comprising  the  CAI  delivery  system  should  be  used  (CAI  Presentation 
and  Simulation  Presentation).  And  If  management  and  scheduling  of  assignments,  testing, 
remediation,  and  enrichment  activities  are  necessary,  support  Is  provided  via  the  CMI  system  (CMI 
Development,  CMI  Operation,  and  Data  Analysis). 


4.4  ISS  Tailoring 


Particular  training  environments  may  require  hardware  devices,  terminal  types,  and/or 
functional  capabilities  that  are  not  currently  provided  In  the  ISS.  With  the  layered  and  modular 
design  of  the  system  (Figure  4),  new  software  and  device  types  can  be  Integrated  Into  the  ISS 
with  minimal  effort.  The  ISS  software  Is  adaptable  In  nature,  with  clean  Interfaces  provided  by 
the  Ada  package  specifications.  A  terminal  definition  file  can  be  updated  to  reflect  the 
characteristics  of  hardware  devices  to  be  added  to  the  system. 


4.S  The  ISS  Micro  As  a  Central  Processor 


By  Inpleiiienting  the  software  on  the  PM200  microcooiputer.  It  has  been  shown  that  the  ISS  can 
operate  on  a  more  economically  feasible  machine  than  minicomputers  and  mainframes.  If,  as  a 
hypothetical  case,  a  training  organization  wanted  to  support  10  students  utilizing  10  curricula, 
10  courses,  and  10  two-hour  CAI  lessons,  approximately  4  MB  of  disk  storage  for  Instructional 
data  would  be  required. 

The  breakdown  of  the  storage  requirements  Is  as  follows: 


1.0  MBytes 
0.3  MBytes 
0.2  MBytes 
2.5  MBytes 

4.0  MBytes 


Storage  for  10  curricula 
Storage  for  10  courses 
Storage  for  10  active  students 
Storage  for  10  two-hour  lessons 

Total  storage  for  Instructional  data 


Also  to  be  considered  are  ISS  program  executables  which  require  approximately  IS  MB  and 
operating  system  storage  which  Is  approximately  10  MB.  The  total  ISS  Winchester  storage 
requirement  for  this  hypothetical  case  Is,  therefore,  29  MB.  Winchester  disk  technology  Is 
available  to  easily  accommodate  this  capacity.  Additional  Winchester  space  would  allow  an 
Increase  to  even  more  curricula,  courses,  and  student  capacity.  Current  microcomputer  technology 
also  allows  large  amounts  of  main  memory. 

With  these  capabilities  currently  available  In  the  PM200  and  In  microcomputer  technology  in 
general,  a  low-cost  alternative  exists  (as  compared  to  minicomputers  and  mainframes)  for  certain 
training  applications.  Figure  6  depicts  an  example  of  the  levels  of  capability  from  which  a 
training  organization  could  choose,  depending  on  available  funds,  storage  requirements,  and 
computing  power  necessary.  CMI  could  be  performed  at  the  central  computer  In  all  cases,  and 
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Figure  6.  Exanple  of  Cost/NrfonMnce  Alternatives. 


depending  on  the  Intelligence  of  the  display  station,  CAl  could  be  performed  either  under  control 
of  the  central  computer  or  the  display  station  processor. 

S.O  CONCLUSIONS  AND  RECOMMENDATIONS 

The  major  goals  set  forth  at  the  beginning  of  the  Standardized  Software  project  have  been 
accomplished.  Applications  software  that  best  satisfies  the  Functional  Description  has  been 
converted  or  developed.  The  developed  system  Is  portable.  Finally,  the  system  has  been 
Implemented  on  a  1ow-cost  minicomputer  and  microcomputer. 

A  follow-on  operational  test  Is  recommended  for  both  the  VAX  and  PM200  implementations. 
During  this  operational  test,  significant  performance  upgrades  should  be  made  to  the  software  In 
order  to  support  the  required  ISS  user  load.  The  test  would  also  allow  a  user  community  to 
evaluate  the  functionality  of  the  ISS.  Appropriate  change  requests  could  be  Issued  to  AFHRL  for 
evaluation.  Enhancements  deemed  beneficial  could  then  be  made  In  a  timely,  orderly,  and 
non-dlsruptlve  manner. 

The  PM200  Implementation  was  to  demonstrate  the  feasibility  of  ISS  transportability  and 
execution  of  the  ISS  on  a  microcomputer.  While  both  capabilities  have  been  demonstrated, 
performance  and  Winchester  disk  size  Issues  need  to  be  addressed  before  the  PM200  can  be 
considered  a  production  Implementation.  Higher-speed,  larger-capacity  Winchester  drives  are  now 
available  and  can  be  placed  In  existing  slots  In  the  PM20D.  These  are  recommended  as 
replacements  for  the  smaller,  slower  drives  used  during  the  Standardized  Software  project. 

Upgrade  of  the  PM200  UNIX  system  Is  also  recommended  to  provide  more  portability. 

Finally,  consideration  should  be  given  to  development  of  a  generic  data  converter  In  order  to 
transport  ISS  courseware.  With  the  differences  In  data  packing  formats  of  the  many  Ada  compilers 
that  are  and  will  come  Into  existence.  It  will  be  necessary  to  easily  convert  those  different 
formats.  By  developing  a  generic  data  converter,  courseware  portability  (as  well  as  software 
portability)  becomes  more  feasible. 
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